Switch mesh core module asset from hardcoded ARTIFACTORY to GITHUB release - #1695
Switch mesh core module asset from hardcoded ARTIFACTORY to GITHUB release#1695mikhailm-coder wants to merge 1 commit into
Conversation
…lease CoreModule.js now downloads from the same meshagent release archives as the binary, versioned by openframe.client-versions.mesh, so machines pick up new cores on every mesh version bump instead of serving a frozen JAR resource. Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (2)
📝 WalkthroughWalkthroughMeshCentral core module downloads now use GitHub sources for Windows and macOS. MeshCentral version overrides now apply to both the agent and its core module asset. ChangesMeshCentral core module
Estimated code review effort: 2 (Simple) | ~10 minutes Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
| public class IntegratedToolAgentInitializer implements ApplicationRunner { | ||
|
|
||
| private static final String OSQUERY_ASSET_ID = "osqueryd"; | ||
| private static final String MESHCENTRAL_CORE_MODULE_ASSET_ID = "meshcentral-core-module"; |
There was a problem hiding this comment.
Why not approach we discussed before?
Mesh have native way for the core module management.
There was a problem hiding this comment.
Old pr, working on discussed solution atm; Closing this👌
Why
Deployed OpenFrame machines get the mesh agent's JS core from a frozen snapshot baked into this repo's JAR (
ToolAgentFileController+openframe-client-core/src/main/resources/meshcentral-core-module, markedTODO: remove after github artifact is implemented). Edits toCoreModule.jsin the meshagent repo never reach machines. The GITHUB asset mechanism this TODO was waiting for now exists and is proven by fleet'sosquerydasset — this PR migrates the mesh core module onto it.What
meshcentral-agent.json:meshcentral-core-moduleasset flipsARTIFACTORY→GITHUB, withdownloadConfigurationspointing at the same meshagent release archives that deliver the binary (targetFileName: CoreModule.js). One artifact, one tag — core/binary skew becomes impossible.IntegratedToolAgentInitializer: the asset's version is wired toopenframe.client-versions.mesh(mirrors the osqueryd pattern), so every mesh version bump re-downloads the core on deployed machines via the standard asset-update path.ToolAgentFileController, the JAR blob, and the client's ARTIFACTORY path are deliberately left in place — old installation messages sit on persistent NATS topics and can be replayed. Cleanup is a follow-up PR after the fleet migrates.Do not deploy this against a mesh version whose release archives lack
CoreModule.js:CoreModule.jsships in meshagent archives starting with the release cut from Ship CoreModule.js in both release archives meshagent#79 (expected0.1.1). Releases ≤0.1.0do not contain it.openframe.client-versions.meshpoints at an older release when this deploys, the asset download fails and aborts fresh mesh installs (existing machines are unaffected —hasAssetChangestreats the null→versioned transition as no change, so nothing is published until the next mesh version bump; that bump-driven rollout is the intended semantics).MESH_CLIENT_VERSIONbumped to it → this deploys.Known accepted trade-offs
meshcentral-agent-versionfeature pin only the binary (meshcentral-servertool id), not this asset — a pinned build would take the asset from the server-sent version. Follow-up candidate intool_version_overrides.🤖 Generated with Claude Code
Summary by CodeRabbit